home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1264 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.6 KB

  1. Path: newsfeed.internetmci.com!xmission!news
  2. From: tknarr@xmission.com  ( Todd Knarr )
  3. Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.edu,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3
  4. Subject: Re: Hungarian notation
  5. Date: 10 Jan 1996 05:06:18 GMT
  6. Organization: Chaos Central
  7. Message-ID: <4cvhga$5rn@news.xmission.com>
  8. References: <30C40F77.53B5@swsbbs.com> <30EF0415.6FE1@tus.ssi1.com> <1996Jan7.045815.8676@ohstpy> <4cpb00$nqk@news.xmission.com> <4crm6i$24mi@navajo.gate.net> <4csi2t$gsa@news.xmission.com> <4ctomq$1pi8@hopi.gate.net>
  9. Reply-To: tknarr@xmission.com ( Todd Knarr )
  10. NNTP-Posting-Host: slc133.xmission.com
  11. X-Newsreader: IBM NewsReader/2 v1.2
  12.  
  13. In <4ctomq$1pi8@hopi.gate.net>, feathers@gate.net (Michael Feathers) writes:
  14. >This may seem like a quibbling point, but in OOP it should be a natural
  15. >assumption (because of polymorphism) that all objects of derived
  16. >classes should perform in a manner appropriate to their class in
  17. >the context of their base classes interfaces.  This is information
  18. >hiding, in much the same way as function names hide implementation 
  19. >yet provide semantic information.  If this is not the case, then the 
  20. >inheritance should be suspect.
  21.  
  22. Except that, if you tell people that the prefix on the name tells the
  23. type of the variable, they may believe you. If they do, in the case
  24. of my example, they might well say "Oh, the prefix says that's a Stall."
  25. and merrily proceed to locate the Stall class and begin working with
  26. it. If they are not intimately familiar with the design of my code
  27. ( which they may not be, work assignments tend to be handed out based
  28. on who is available rather than who is most familiar with a given bit
  29. of code ), they may assume they can trust the prefix to be right and
  30. skip checking the prototype, the class heirarchy and the like and go
  31. right to the class that the variable *says* it is rather than finding
  32. out what it *really* can be. The end result will be, at the very best,
  33. a simple failure of their changes to work. At worst they'll have a
  34. 16 megabyte core dump on their hands.
  35.  
  36. >Why never a Stall?  If Stall's interface is present in any of its derived
  37. >classes, Stall calls should be resolved.
  38.  
  39. Simple: Stall is merely the base class, and objects of it are *only* created
  40. during program initialization as a bookkeeping device to keep track of
  41. information while the program determines the actual current status of the
  42. shower stall the Stall object represents.
  43.  
  44. Once you get into the subclasses, you get serious behavior differences.
  45. For instance, Stall objects do not respond to changes in the physical stall
  46. they represent. The routines are there, but they merely return. Each
  47. subclass implements different behavior to a different set of changes, as
  48. appropriate.
  49.  
  50. >True enough, but I think that new OOP programmers should drill it into
  51. >their heads that references==pointers as far as polymorphism goes (and
  52. >in other ways too).  Polymorphism has to change the way that you understand
  53. >code.  We are not in Kansas any more. 
  54.  
  55. Assuming they check the prototype and then check the class heirarchy to
  56. determine that they are dealing with a polymorphic type. As I said, this
  57. conflicts with HN's theory that the prefix of the variable name itself
  58. accurately reflects the actual type of the variable. This is exactly the
  59. same situation as I run into with comments. Accurate comments are a
  60. blessing, but the only thing worse than no comments at all is lots of
  61. comments that don't reflect the actual code. If you have no comments at
  62. all you automatically know you need to read the code, but if you have
  63. lots of comments that are wrong but that you are told you can believe,
  64. you may make the mistake of believing them at the wrong time and wind up
  65. wasting two weeks wondering why your changes keep breaking the code when
  66. according to the comments they shouldn't.
  67.  
  68. Yes a good programmer should check first. In an ideal world, all programmers
  69. will. In the real world, though, somebody who's never seen the code before
  70. gets told to make a major change to it and have it ready for release by
  71. Thursday, and they've already got 4 other high-priority projects they need
  72. to get finished, and checks to make sure what you are told is true really
  73. is true sometimes get skipped. My experience is that every single time
  74. that happens I get bit by it, so I tend to avoid things that would increase
  75. the number of places that could happen.
  76.  
  77. --
  78. Todd Knarr : tknarr@xmission.com      |  finger for PGP public key
  79.                                       |  Member, USENET Cabal
  80.  
  81. Seriously, I don't want to die just yet.  I don't care how
  82. good-looking they are, I! don't! want! to! die!"
  83.                                         -- Megazone ( UF1 )
  84.  
  85.